In known graphical user interfaces according to the art, scroll bars are used when the available data is larger than the size of the visible window given to the control. For controls that contain rows of data, such as tables or lists of items, a common scenario is for the application to show the user the amount of available data by the size of the scroll bar thumb as a percentage of the total available size in which the thumb can move (the size of the scroll bar) and as the user moves the scroll bar, the rows in the control change to show the rows in the visible window from the total number of rows, as represented by the position of the thumb relative to the total size of the scroll bar. Scroll bars to allow paging through lists of data are well described in the patent literature and are used in familiar windowing software to show files within a folder where the user can move the scrollbar to see items off the page currently being displayed.
An example of a graphical user interface window is shown in FIG. 3, wherein the salient features are the line numbers 300 indicating the rows of data 302 being displayed, the scrollbar 304, and the thumb 306, which is well known in the art as a means adapted to be captured by, for example, the mouse and slide down the scrollbar 304 to bring into view additional rows of data 302.
A problem exists where the total data through which the user is scrolling is a set of data collected from a data store at different points in time and that data can change over time. The effect of this is that rows retrieved in one fetch are not necessarily coherent with rows retrieved in a later fetch. This occurs typically if the application cannot, for performance reasons because of bandwidth and other client/server issues, fetch all of the rows at once from the data store. In these situations what typically occurs is that if the total number of available rows can be initially quickly retrieved, items are only retrieved from the data store to fulfill the request to display the rows to the user in the visible area of the control plus some additional rows for “headroom”. As the user scrolls the control, the application realizes that the rows that need to displayed are not yet in the application, so a fetch to the back-end data store occurs to retrieve the data to create the rows. The effect for users is that they can see quickly the amount of possible rows and the data for the rows in the visible window of their application, with the request being satisfied quickly as only a subset of the total available rows are fetched. If the user scrolls the tree, more rows are retrieved only as required, the net effect being a performance improvement over fetching all of the back end data and turning it into rows at once when the application initially shows the available rows.
However, this performance improvement itself introduces a problem by paging data lazily into a tree because the data for different pages is retrieved at different times determined by when the user scrolls the control. If the data can change over time, then the list being presented to the user is not a coherent set of data relative to itself.
One real world scenario where this occurs is if the rows represent operating system resources, such as files, and the data attribute being compared is a time of last update, or, for a list of processes, where the data attribute is a task priority, memory size or elapsed time. It will be clear to one of ordinary skill in the art that decisions based on comparisons of this potentially volatile data will be at least occasionally erroneous.
Consider, for example, FIG. 4, in which thumb 306 has been slid down scrollbar 304 to bring into view further rows of data 300, as shown by the change in rows of data 300, where row number 8 from the bottom of the previous display of FIG. 3 is now at the top and additional rows 9 to 15 are shown. If data from any of these additional rows was changed between the time of the original display for FIG. 3 and the time of the scrolled display of FIG. 4, this fact would not be known to the user, and erroneous decisions based on the data might be made.